Remarks 

Status of application 

Claims 1-48 were examined and stand rejected in view of prior art and for 
technical reasons. Applicant has amended claims 1, 21 and 36 to address the rejection of 
Applicant's claims under 35 U.S.C. Section 101. In view of the amendments made and 
the following remarks, reexamination and reconsideration are respectfully requested. 

The invention 

For a concise statement of Applicant's invention, please refer to the Summary of 
Invention in Applicant's previously filed Appeal Brief. 

General 

A. Section 101 Rejection 

Claims 1-48 stand rejected under 35 U.S.C. 101 as being directed towards non- 
statutory subject matter. Although Applicant respectfully believes that the Examiner has 
incorrectly construed Applicant's specification as stating that the elements of Applicant's 
invention can only be implemented in software, Applicant has amended independent 
claims 1 and 36 by adding claim limitations of a computer having at least a processor and 
memory. Applicant has also amended independent claim 21 to clarify that Applicant's 
claimed method is implemented in a computer having at least a processor and memory. 
These claim limitations find support in Applicant's specification which expressly states 
that elements of Applicant's invention may be implemented in hardware, software or 
firmware (or combinations thereof). This is expressly stated, for example, at paragraph 
[0036] of Applicant's specification as follows: "...the corresponding apparatus element 
may be configured in hardware, software, firmware or combinations thereof (see e.g., 
Applicant's specification, paragraph [0036] emphasis added). Applicant also describes in 
detail a computer system environment in which the present invention may be 
implemented (see e.g., Applicant's specification, paragraphs [0038]-[0048]; see also, Fig. 
1 and Fig. 2). In view of these amendments, it is respectfully submitted that the rejection 
of claims 1-48 under Section 101 is overcome. 
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Prior art rejections 

A. Section 102 rejection: Cohen 

Applicant's claims 1-2, 4-9, 18-22, 24, 28-31, 33-37, 39, 43-46 and 48 stand 
rejected under 35 U.S. C. 102(e) as being unpatentable over U.S. Published Application 
No. 2003/0097331 A of Cohen (hereinafter "Cohen"). In the current Office Action the 
Examiner has reopened prosecution in response to Applicant's Appeal Brief, which 
appealed the Examiner's prior rejection of Applicant's claims based on a combination of 
twelve different references. The Examiner now relies on eight references in rejecting 
Applicant's claims and relies on Cohen alone in rejecting Applicant's claims 1-2, 4-9, 18- 
22, 24, 28-31, 33-37, 39, 43-46 and 48. However, under Section 102, a claim is 
anticipated only if each and every element as set forth in the claim is found, either 
expressly or inherently described, in the prior art reference. As described below in detail, 
Cohen fails to teach each and every element set forth in Applicant's claims and therefore 
fails to establish anticipation of the claimed invention under Section 102. 

Cohen discloses a "mctabank" Internet banking system that provides a corporate 
or individual consumer with the ability to open an Internet financial vehicle referred to as 
a "webbank" (Cohen, paragraph [0004]). Cohen describes that a webbank is located on 
the World Wide Web and enables a corporate or individual user/owner to perform certain 
banking functions as an Internet banking "subsidiary" of a true bank, which Cohen refers 
to as a "metabank" (Cohen, paragraph [0005]). In other words, Cohen's solution enables 
corporate and individual users to perform certain of their own banking functions via the 
Internet. 

Cohen describes that a user can provide his credit card company with the 
webaddress of the user's webbank, so that whenever the customer's credit card is used, 
records of the transaction are sent to the webaddress with details about the transaction 
such as vendor, place of purchase, amount of purchase, etc. (Cohen, paragraph [0273]). 
This enables the customer to look at the website to review recent activity; pay bills and so 
forth (Cohen, paragraph [0274]). Information from a provider (e.g., in an email) can also 
be downloaded into a spreadsheet or into a personal database linked to the website such 
as Microsoft Access or Quicken (Cohen, paragraph [0277]). Here, Cohen goes on to 
describe that "the information in this personal database maintained for that customer can 
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then be consolidated and manipulated by the customer in whatever manner the customer 
desires " (Cohen, paragraph [0277], emphasis added). The Examiner contends that these 
teachings of Cohen of downloading financial information received via email into a 
personal database or spreadsheet are equivalent to Applicant's claimed solution for 
consolidation of financial transaction information. Applicant respectfully disagrees. 
Comparison of the referenced teachings, as well as the balance of the Cohen reference, 
finds that Applicant's claimed invention is distinguishable from Cohen in a significant 
number of respects. 

Applicant's solution does not simply operate to summarize transaction records 
(e.g., transactions made using a particular credit card) over a given period of time. 
Instead, the focus of Applicant's claimed invention is on consolidating transaction data 
from a live, user-accessible banking system with transaction data imported from data files 
(e.g., BAI files received and processed after the end of the business hours). Applicant's 
solution recognizes that today's real-time banking transactions are tonight's file-based 
transactions and therefore the two sets of transaction data from different sources (e.g., 
data files typically received and processed at night and real-time transaction data from 
"live" systems) include large quantities of duplicate data. Applicant's solution operates to 
consolidate data from file-based sources with data from the live system while also 
eliminating duplicate data by replacing real-time transaction data from the live system 
with the officially posted transaction data when the official transaction data is available 
(e.g., at the end of the day). This is described, for instance, in Applicant's specification as 
follows: 

Assume, for example, that a bank receives a set of BAI files once per day and 
processes these files each day at midnight. During a particular day, a user (i.e., 
bank account holder) may request account data for a particular account 1234. In 
response, the reporting module 480 may obtain current data from the live system 
470 and use the data consolidator 450 to add the live data into the data 
consolidator's repository 460. The combined information from the live system 
and previously received data files relating to the particular account 1234 may then 
be displayed to the user in response to his or her request. The user may then issue 
a bill payment from this account at 2 pm in the afternoon of that same day. The 
data consolidator will update the account information to reflect the bill payment 
(based on information about the bill payment in the live system 470). That 
evening at midnight a new set of BAI files is received and processed, including a 
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BAI file containing information relating to account 1234. The information in this 
BAI file may duplicate the information that came from the live system (e.g., 
because the BAI file includes a record of activity over the past 24 hours on 
account 1234). For example, the BAI file may include information reflecting the 
bill payment made from the account at 2 pm. When the system of the present 
invention processes data files (e.g.. BAI files), the system will automatically 
purge any corresponding information in the repository which is marked as live 
from the user-accessible system. In this example, the bill payment record from 
the live system will be deleted as it is duplicated in the BAI file . 

(Applicant's specification, paragraph [0072], emphasis added) 

As illustrated above, the consolidation performed by Applicant's invention 
includes removing duplicate transaction data. Removal of duplicate data reduces the 
quantity of the data that is maintained, provides increased consistency and improves 
performance. This feature is also included in the claim limitations of Applicant's claims. 
For example, Applicant's claim 1 includes the following claim limitations: 

a data consolidator for receiving parsed information from the file importer, 
consolidating said parsed information with transaction information from a user- 
accessible system to create consolidated transaction records , assigning a unique 
identifier to each consolidated transaction record for an account, and storing said 
consolidated transaction records, wherein consolidating said parsed information 
includes removing transaction information derived from the user accessible 
system that is duplicated in said parsed information from the data files ; and 

(Applicant's claim 1, emphasis added) 

Applicant's review of Cohen finds no mention whatsoever of eliminating 
duplicate information or, more generally, of consolidating information imported from 
file-based sources with information from a user-accessible system. Instead, Cohen 
describes that any consolidation or manipulation of data is left to the user as follows: 

The information in this personal database maintained for that customer can then 
be consolidated and manipulated by the customer in whatever manner the 
customer desires . 

(Cohen, paragraph [0277], emphasis added) 

The only other reference to "consolidated" information in Cohen is that Cohen 
mentions that in addition to receiving real-time notification of transactions as they occur, 
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customers can additionally receive "automatic statements or consolidations" of 
information on a periodic basis, such as for the day, the month, the year, and so forth 
(Cohen, paragraphs [0278]-[0279]). Significantly, Cohen notes that this processing "can 
be as an alternative to viewing periodic (e.g., daily) updates or in addition to it" (Cohen, 
paragraph [0278]). Thus, it is clear that Cohen's system does not eliminate duplicate 
data. Additionally, Cohen provides no teaching of combining data from a live system 
with parsed information extracted from data files. 

Another distinctive feature of Applicant's claimed invention is that Applicant's 
system supports additional (i.e., custom) data fields in data files (e.g., BAI files) that are 
received. Moreover, it does so without having to modifying the underlying schema. One 
of the complications in processing BAI data files and storing them in a repository is that 
financial institutions frequently extend the BAI file format to provide additional (i.e., 
custom) fields or lines. Applicant's solution provides for handling and storing this 
additional information in the repository even though it may not be defined as a standard 
data element (i.e., in standard fields which are expected). It does so by creating an 
Extensible Markup Language (XML) representation of the additional information and 
storing this XML representation in the repository (see e.g., Applicant's specification, 
paragraphs [0066]-[0067]). These features are included as limitations of Applicant's 
claims including, for instance, the following limitations of Applicant's claim 1 : 

a file importer for importing data files from a first source and processing each 
data file to create parsed information for each transaction present in the data file 
and represent any additional information present in the data file in Extensible 
Markup Language (XML) format; 

(Applicant's claim 1) 

When information from the BAI file is subsequently retrieved from the repository 
for presentation to a user, this additional information in XML format is reassembled for 
presentation to the user with the rest of the data from the BAI file (see e.g., Applicant's 
specification, paragraph [0066]). This feature is also described in Applicant's claims (see 
e.g., Applicant's claim 9). 

The Examiner references Cohen for the corresponding teachings. However, 
Cohen simply states that information may be linked using XML as follows: 
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Moreover, in the preferred embodiment, the website is linked to financial data and 
information at the metabank using existing technologies. In one such 
embodiment, the webbank is linked to financial databases at the overseer bank 
using XML and/or any other suitable programming language currently available 
(or later developed in the art) for sharing and/or transferring information, or 
linking information to databases, including information in a webpage. In this 
embodiment, the outer template of the webbank's webpage, presenting the format 
of the website, is preferably programmed using HT or some other available or 
appropriate language, with the underlying financial data and information being 
linked to the webbank using a language such as XML. 

(Cohen, paragraph [0090]) 

Additionally, Cohen makes no mention of retrieving the XML representation 
from the repository in response to a user request (e.g., as provided in Applicant's claim 
9). The Examiner references paragraph 0277 of Cohen for the teachings corresponding to 
Applicant's claim 9; however, Cohen simply describes that a website "is programmed 
using XML or another suitable method" (Cohen, paragraph [0277]). Respectfully, such 
teachings do not teach or suggest Applicant's claim limitations of an XML representation 
of data which is stored and can be retrieved in response to a user request for financial 
transaction information (see e.g., Applicants' claim 9). 

Additionally, Applicant's methodology provides for ordering the transaction 
information and assigning a unique identifier (e.g., sequence number) to each transaction 
stored in the repository (see e.g., Applicant's specification, paragraph [0069]). This 
unique identifier facilitates paging the transaction information to the user in manageable 
groups or "chunks" of information, such as in groups of ten transactions organized based 
on sequence number (see e.g., Applicant's specification, paragraphs [0069]-[0070]). The 
user may, for example, then navigate through the transactions in sequence. This feature 
is also included as limitations of Applicant's claims. For example, Applicant's claim 1 
includes the following claim limitations: 

a data consolidator for receiving parsed information from the file importer, 
consolidating said parsed information with transaction information from a user- 
accessible system to create consolidated transaction records, assigning a unique 
identifier to each consolidated transaction record for an account , and storing said 
consolidated transaction records, wherein consolidating said parsed information 
includes removing transaction information derived from the user accessible 
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system that is duplicated in said parsed information from the data files; and 
a reporting module for receiving a request for financial transaction information 
for a particular account and presenting consolidated transaction records for the 
particular account to the user in response to the request, wherein the user may 
navigate through said consolidated transaction records based upon said unique 
identifier . 

(Applicant's claim 1, emphasis added) 

The Examiner again relies on Cohen as providing the corresponding teachings. 
However, Applicant's review of the Cohen reference, finds no mention whatsoever of 
assigning a sequence number or other unique identifier to each transaction record. As 
Cohen makes no mention of a unique identifier, Cohen also cannot teach using such 
identifier to facilitate display of the information to the user as with Applicant's claimed 
invention. 

All told, Cohen does not include teachings of a consolidation system that 
consolidates real-time transaction data from a live system with file-based transaction 
data. Additionally, Cohen does not include teachings of removing duplicate data in the 
process of consolidating data from different sources. Furthermore, Cohen does not teach 
converting additional data fields in input data files into XML format and storing it in the 
repository so that it can later be provided to a user when requested. Cohen also fails to 
include any teaching or suggestion of assigning a unique identifier to each transaction 
and using this identifier to assist the user in navigating through transaction data. 
Therefore, as Cohen does not include all the limitations of Applicant's claims it is 
respectfully submitted that Applicant's claims distinguish over the prior art and overcome 
any rejection under Section 102. 

B. First Section 103 Rejection: Cohen and Campbell 

Claims 3, 23 and 38 stand rejected under 35 U.S.C. 103(a) as being unpatentable 
over Cohen (above) in view of U.S. Patent 6,856,970 of Campbell et al (hereinafter 
"Campbell"). As to these claims, the Examiner relies on Cohen as substantially teaching 
the claimed invention, but acknowledges that Cohen fails to teach at least one file adapter 
for extracting data from a particular type of data file, such as a BAI file. Therefore, the 
Examiner adds Campbell as providing these teachings. 
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Under Section 103(a), a patent may not be obtained if the differences between the 
subject matter sought to be patented and the prior art are such that the subject matter as a 
whole would have been obvious at the time the invention was made to a person having 
ordinary skill in the art to which the subject matter pertains. To establish a prima facie 
case of obviousness under this section, the Examiner must establish: (1) that there is 
some suggestion or motivation, either in the references themselves or in the knowledge 
generally available to one of ordinary skill in the art, to modify the reference or to 
combine reference teachings, (2) that there is a reasonable expectation of success, and (3) 
that the prior art reference (or references when combined) must teach or suggest all the 
claim limitations. (See e.g., MPEP 2142). The Cohen and Campbell references, even 
when combined, fail to meet the requisite condition of teaching or suggesting all of 
Applicant's claim limitations. 

Applicant's claims are believed to be allowable for at least the reasons cited above 
(as to the Section 102 rejection) pertaining to the deficiencies of Cohen as to Applicant's 
invention. Campbell does not cure any of these deficiencies of Cohen. Although 
Campbell describes a B AI format mapper which accounts for different interpretations of 
BAI used at different banks, it does not include any teaching of a system that consolidates 
real-time transaction data with file-based transaction data comparable to Applicant's 
claimed invention. Accordingly, Campbell does not cure any of the above-described 
deficiencies of Cohen as to Applicant's invention. As the combined references do not 
include all the limitations of Applicant's claims it is respectfully submitted that 
Applicant's claims distinguish over the combined references and overcome any rejection 
under Section 103. 

C. Second Section 103 Rejection: Cohen and Hopkins 
Claims 10-12, 25 and 40 stand rejected under 35 U.S.C. 103(a) as being 
unpatentable over Cohen (above) in view of U.S. Published Application 2005/0172137 of 
Hopkins et al (hereinafter "Hopkins"). Applicant's claims are believed to be allowable 
for at least the reasons discussed in detail above pertaining to the deficiencies of Cohen 
as to Applicant's invention, none of which are cured by Hopkins. Applicant also believes 
these dependent claims are allowable for the additional reasons discussed below. 



16 



As discussed previously, Applicant's solution provides for assigning a unique 
identifier to each transaction stored in the repository to facilitate paging the transaction 
information to the user in manageable groups or "chunks" of information. Applicant's 
claim 10, for instance, adds that the unique identifier comprises a sequence number. 
Claim 1 1 adds that the sequence number is assigned per account and per type of 
transaction. Additionally, claim 12 provides that consecutive sequence numbers are 
assigned to transactions records of a given type for a particular account. Although 
Hopkins discusses sequence numbers, it assigns sequence numbers based on the 
particular terminal at which the transaction originates (Hopkins, paragraph [0025]). 
Thus, assuming the terminal that is involved in Hopkins' solution is a particular ATM, 
Hopkins unique identifier identifies the ATM and issues consecutive sequence numbers 
for transactions at that ATM. This is not the same as assigning sequence numbers "per 
account and type of transaction" as provided by Applicant's claimed invention. 

Consider, for instance, the following example of a user taking cash from an ATM. 
With Hopkins' solution, when an individual took cash from a given account at a first 
ATM, Hopkins' system would assign a sequence number based on the current sequence at 
that particular ATM. Subsequently, if the same user went to another ATM and took cash 
from the same account, Hopkins' system would assign a completely different sequence 
number. In contrast, with Applicant's invention the same sequence would be used for 
assigning a sequence number to the two transactions as they are both for the same 
account and are the same type of transaction (see e.g., Applicant's specification, 
paragraph [0069]) Additionally, assuming there were no intervening transactions on the 
account (and a consecutive paging scheme is selected as described at paragraph [0069] of 
Applicant's specification), consecutive sequence numbers would be assigned to the two 
cash withdrawals made from the two different ATMs by Applicant's solution. Thus, 
Hopkins does not teach or suggest these specific limitations of Applicant's claims 10-12, 
25 and 40. 

Accordingly, as the combined references do not include all the limitations of 
Applicant's claims it is respectfully submitted that Applicant's claims distinguish over the 
combined references and overcome any rejection under Section 103. 
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D. Third Section 103 Rejection: Cohen, Hopkins and Ferlauto 
Claims 13-14, 26 and 41 stand rejected under 35 U.S.C. 103(a) as being 
unpatentable over Cohen (above) in view of Hopkins (above),and further in view of U.S. 
Patent 6,895,926 of Ferlauto et al (hereinafter "Ferlauto"). Again, these claims are 
believed to be allowable for the reasons discussed in detail as to the deficiencies of 
Cohen and Hopkins as to Applicant's claimed invention, none of which are cured by 
Ferlauto. Ferlauto describes an address consolidating system including a name and 
address database in which duplicate names and address are consolidated by matching 
name and address and e-mail address simultaneously (Ferlauto, Abstract). As Applicant's 
claimed invention relates to consolidation of financial transaction records, Ferlauto's 
system for consolidation of name and address data appears only marginally relevant. 
Applicant also believes that Ferlauto does not teach or suggest the specific limitations of 
Applicant's dependent claims 13-14, 26 and 41 for the following additional reasons. 

The Examiner adds Ferlauto for the teachings of a data consolidator that assigns 
date-based sequence numbers to transactions of a given type for a particular account 
(Applicant's claim 13, 26 and 41) and that is user configurable to assign a unique 
identifier using a selected one of consecutive sequence numbers and date-based sequence 
numbers. The Examiner references Ferlauto at column 16, lines 63-67 for such 
teachings. However, column 16, lines 63-67 of Ferlauto includes Ferlauto's claim 3 
which reads as follows: 

3. A method for matching and consolidating addresses in a name and address 
database according to claim 2 wherein said at least one new field comprises at 
least one of a file code field, a sequence number field, a transaction date field, and 
a value field. 

(Ferlauto column 16, lines 63-67) 

As illustrated above, Ferlauto describes a sequence number field and a separate 
transaction date field. Applicant's review of the balance of the Ferlauto reference finds 
that although Ferlauto describes several different kinds of sequences, Ferlauto's general 
approach is for the sequence numbers to go up by one for each subsequent record (see 
e.g., Ferlauto col. 2, line 65 to col. 3, line 6). Ferlauto also describes a separate 
"transaction date field" (YYYMMDD) which is based on the date the transaction is 
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generated by the file owner (see e.g., Ferlauto, col. 3, lines 6-9). However, this date field 
is described as being separate from the sequence number and Applicant's review of the 
reference finds no mention of providing for the user to select between date -based and 
consecutive sequencing as provided with Applicant's claimed invention. Thus, as the 
combined references do not include all the teachings of Applicant's claims, Applicant 
respectfully submits that its claimed invention distinguishes over these references. 

E. Fourth Section 103 Rejection: Cohen and Battat 

Claim 15 stands rejected under 35 U.S.C. 103(a) as being unpatentable over 
Cohen (above) in view of U.S. Published Application 2006/0143239 of Battat et al 
(hereinafter "Battat"). Claim 15 is believed to be allowable for the reasons discussed in 
detail as to the deficiencies of Cohen as to Applicant's claimed solution for consolidation 
of financial transaction records. Battat does not cure any of these deficiencies as Battat 
simply describes a method and apparatus for maintaining data integrity across distributed 
computer database systems. Additionally, Applicant respectfully believes that Battat's 
teachings of a commit operation which collapses all the operations in a given transaction 
into one undo-able operation are not comparable to Applicant's claim limitations of a data 
consolidator that provides for undoing transaction records created from a particular file in 
response to a user request to undo a particular file. Accordingly, as the combined 
references do not include all the teachings of Applicant's claims, Applicant respectfully 
submits that its claimed invention overcomes the Section 103 rejection. 

F. Fifth Section 103 Rejection: Cohen, Battat and Smith 

Claims 16 and 17 stand rejected under 35 U.S.C. 103(a) as being unpatentable 
over Cohen (above), in view of Battat (above) and further in view of U.S. Published 
Application 2002/0042975 of Smith (hereinafter "Smith"). Claims 16 and 17 are 
dependent on claims 1 and 15 and are, therefore, believed to be allowable for the reasons 
set forth above as to the deficiencies of Cohen and Battat as to these independent and 
intervening claims. Smith does cure any of these deficiencies. Additionally while Smith 
describes identifying dependent files, Smith makes no mention of undoing or 
reprocessing any files or dependent files as provided in Applicant's specification and 
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claims. Furthermore, the Examiner references Cohen at paragraphs 0277-0278 for the 
teachings of Applicant's claim 17 of reprocessing of dependent files by the data 
consolidator in response to a user request to undo a particular file. However, Cohen 
makes no mention of undoing transaction records derived from a particular file in 
response to a user request, nor does Cohen (or the other references) describe identifying 
and reprocessing records which are dependent on the file being undone as provided in 
Applicant's specification and claims. For the reasons set forth above, Applicant 
respectfully submits that its claimed invention distinguishes over the combined references 
and overcomes the Section 103 rejection. 

G. Sixth Section 103 Rejection: Cohen and Schulze 

Claims 27 and 42 stand rejected under 35 U.S.C. 103(a) as being unpatentable 
over Cohen (above) in view of U.S. Published Application 2006/0041493 of Schulze et al 
(hereinafter "Schulze"). Applicant's claims are believed to be allowable for at least the 
reasons described above pertaining to the deficiencies of Cohen. Schulze does not cure 
these deficiencies as the referenced teachings of Schulze simply describe making a back- 
up file of downloaded identification data and routing codes and storing it in an off-site 
storage system. Therefore, Applicant respectfully submits that its claimed invention 
distinguishes over the combined references and overcomes the Section 103 rejection. 

H. Seventh Section 103 Rejection: Cohen and Osborne 

Claims 32 and 47 stand rejected under 35 U.S.C. 103(a) as being unpatentable 
over Cohen (above) in view of U.S. Published Application 2003/00120619 of Osborne et 
al (hereinafter "Osborne"). Applicant's claims are believed to be allowable for at least the 
reasons described above pertaining to the deficiencies of Cohen. Osborne describes a 
solution for remote monitoring and diagnosing of industrial equipment and, therefore, 
does not cure any of these deficiencies. Therefore, Applicant respectfully submits that its 
claimed invention distinguishes over the combined references and overcomes the Section 
103 rejection. 

Any dependent claims not explicitly discussed are believed to be allowable by 
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virtue of dependency from Applicant's independent claims, as discussed in detail above. 
Conclusion 

In view of the foregoing remarks and the amendment to the claims, it is believed 
that all claims are now in condition for allowance. Hence, it is respectfully requested that 
the application be passed to issue at an early date. 

If for any reason the Examiner feels that a telephone conference would in any way 
expedite prosecution of the subject application, the Examiner is invited to telephone the 
undersigned at 925 465 0361. 

Respectfully submitted, 

Date: June 12, 2009 /G. Mack Riddle/ 

G. Mack Riddle; Reg. No. 55,572 
Attorney of Record 

925 465 0361 
925-465-8143 FAX 
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